Part of JETPACK-1504

Proposed Changes

#109765 added the simplified Jetpack footer to four Calypso pages (Activity Log, Monetize, Traffic, Podcasting) but explicitly left Backup and Scan out due to the additional complexity of testing them. Backup is now closed by the sibling PR #109886. This PR closes the Scan half across all WP.com render paths reachable from /scan/<site-slug>.

Files touched

• client/my-sites/scan/main.tsx — happy-path ScanPage (when the site has scan active). Footer gated on isWpcom. Pattern matches the Backup sibling PR Backup: add Jetpack footer to the WP.com page #109886 and Podcasting from Jetpack: add footer #109765.
• client/my-sites/scan/wpcom-scan-upsell.tsx — WPCOMScanUpsellPage reached via the showUpsellIfNoScan / showUpsellIfNoScanSelfServeFeature middlewares (client/my-sites/scan/index.js), plus the no_connected_jetpack / vp_active_on_site / multisite_not_supported reasons. File is wpcom-only by construction — the scan controller gates between this and ScanUpsellPage (the Jetpack Cloud variant) at isJetpackCloud() || isA8CForAgencies(), so no gate is needed inside the file itself.
• client/my-sites/scan/wpcom-upsell.tsx — simpler WPCOMScanUpsellPage (same export name, different file) reached via ScanAtomicTransferWrapper in wpcom-atomic-transfer.tsx when the site doesn't have the scan feature. Same wpcom-only construction.
• client/my-sites/scan/wpcom-atomic-transfer.tsx — adds footer to the ScanLoadingPlaceholder (the loading state rendered by ScanAtomicTransferWrapper while site features or scan data are still loading). Scan-specific local component, reachable only for non-Jetpack-Cloud sites because wpcomJetpackScanAtomicTransfer short-circuits on isJetpackCloud() || isA8CForAgencies() at the middleware level.

Total diff is 8 added lines across 4 files (one import + one render line per file).

Render path coverage

Scan's route middleware chain (client/my-sites/scan/index.js) means /scan/<site> can resolve to one of several components depending on site plan/features:

Dependency on sibling PR #109886

The Atomic-transfer-activation CTA path routes through the shared <WPCOMBusinessAT /> component at client/components/jetpack/wpcom-business-at/index.tsx. That component is footered in the sibling Backup PR #109886 (in HEADER-008's 3-file expansion). When #109886 merges to trunk, this Scan branch will automatically get the shared fix via rebase/merge.

Until then, on this branch alone, the atomic-transfer CTA state will still be missing a footer. This is acknowledged and expected — merging #109886 first, or merging both together, resolves it. The atomic-transfer state is reached only when a Business-plan WP.com site without Atomic needs to be transferred to get Scan, which is a narrow flow.

Why are these changes being made?

#109765 added the simplified Jetpack footer to four Calypso pages (Activity Log, Monetize, Traffic, Podcasting) but explicitly left Backup and Scan out — quoting that PR's description:

Using the footer at Scan & Backup I'm also leaving for another PR due to a bit more complexity of testing those pages, so this is easier to merge sooner.

Backup is now closed by #109886. This PR closes the Scan half. After both land, JETPACK-1504's checklist will be complete and the parent issue (JETPACK-1391) can tick its remaining Calypso boxes.

Testing Instructions

Before / After (happy path, main.tsx)

Before: Scan page ends at the bottom of the "Don't worry about a thing" status card with empty white space below it — no footer chrome.

After: Same content with a new row at the bottom showing the green Jetpack pill on the left and the "An Automattic airline" byline on the right, matching the existing footer on Activity Log / Monetize / Traffic / Podcasting / Backup.

Steps to verify

1. Happy path: On a WP.com site with Jetpack Scan active, navigate to /scan/<site-slug>. Expected: footer renders at the bottom.
2. Upsell path (Simple/no scan): On a WP.com Simple site without Scan, navigate to /scan/<site-slug>. The page renders the upsell (WPCOMScanUpsellPage from either wpcom-scan-upsell.tsx or wpcom-upsell.tsx depending on the plan/feature combo). Expected: footer renders at the bottom.
3. Loading state: Reload the Scan page while the feature/scan-data fetch is in flight. Expected: the ScanLoadingPlaceholder (shown during the brief loading flash) also renders the footer.
4. Jetpack Cloud variant (if available): Navigate to the same Scan page from the Jetpack Cloud variant and confirm the footer does not render — Jetpack Cloud has its own chrome and the isWpcom / controller-level isJetpackCloud() gates suppress the new footer for that platform.
5. Switch to a narrow viewport (≤460px) and confirm the footer wraps cleanly.

DOM check

Quickly verifiable from the browser console:

document.querySelector( 'footer.jetpack-footer' )
// → <footer class="... jetpack-footer" aria-label="Jetpack" role="contentinfo">…</footer>

To confirm there's no duplicate footer rendering:

document.querySelectorAll( 'footer.jetpack-footer' ).length
// → 1

Local validation already performed

Desktop:

• ✅ curlingforbeginners9.wpcomstaging.com (Atomic with scan → main.tsx happy path): footer present, single instance

Mobile viewport (390×844, ≤460px breakpoint):

• ✅ Simple upsell path on willstestdotblog.wordpress.com (routes via ScanAtomicTransferWrapper → wpcom-upsell.tsx::WPCOMScanUpsellPage): footer renders below the "What is Jetpack?" section, wraps cleanly, single instance
• ✅ Atomic happy path on curlingforbeginners9.wpcomstaging.com (routes via main.tsx::ScanPage): footer renders below the "Don't worry about a thing" status card, wraps cleanly, single instance

The wpcom-scan-upsell.tsx (full upsell with branching body) and ScanLoadingPlaceholder paths use the exact same pattern as the verified paths (import + <JetpackFooter /> after </Page> inside <Main>) and were code-reviewed rather than visually captured. The loading state is a transient flash too brief to reliably capture with agent-browser.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes? — N/A, wiring change with no logic to test
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)? — Simple verified on willstestdotblog.wordpress.com, Atomic verified on curlingforbeginners9.wpcomstaging.com. Self-hosted Jetpack n/a (these code paths are wpcom-only by construction).
• Have you checked for TypeScript, React or other console errors? — none in local build; pre-commit Prettier ran clean
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2). — <footer role="contentinfo" aria-label="Jetpack"> inherits the same a11y as the existing JetpackFooter usages
• Have you used memoizing on expensive computations? — N/A, no new computations
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)? — no new strings; the footer's "Jetpack" / "An Automattic airline" labels live in JetpackFooter itself and are already translated
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? — N/A, no new strings
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)? — no, no tracking or data changes